1. Field of the Invention
The present disclosure relates generally to Inter-Process Communication, and more particularly to systems and methods for efficiently guaranteeing such communications in a connectionless packet architecture.
2. Description of Related Art
In multi-processor systems, applications running on different processors can communicate by way of packets transferred between the processors. Several methods currently exist for implementing Inter-Process Communication (IPC).
One method for implementing IPC is with the Transmission Control Protocol (TCP). TCP is a connection-oriented transport protocol originally described in Postel, J., “Transmission Control Protocol—DARPA Internet Program Protocol Specification”, RFC 793, DARPA, September 1981. TCP operates above the Internet Protocol (IP) network layer protocol, providing a tool for computer applications to communicate with other applications across an IP network. When a TCP connection is established between two applications, TCP/IP provides a number of services for the packet communications between the two applications. TCP reorders packets received out of order, automatically retransmits lost packets in a stream, prevents packet duplication, checks for transmission errors, and implements flow control procedures, including a windowing algorithm that limits the amount of data a sender can transmit without all prior transmissions being confirmed first.
To set up a TCP/IP connection, both applications that desire to communicate must bind to a “port” on their local processor, where the port is a sixteen-bit unsigned integer. One of the applications then requests that TCP negotiate a connection with a port on a remote processor, via specification of a “socket” that comprises the IP address associated with the remote processor and the port number associated with the application running on that processor. When a packet arrives at the TCP layer on a processor, the specific TCP connection is identified by the combination of a source socket (the source IP address and source port) and the destination socket (the destination IP address and destination port).
FIG. 1 illustrates an IPC network configuration 100 between two processors that use TCP/IP for delivery of IPC services. The first processor executes three applications A1, A2, and A3 (which could be any application that desires access to a network service), and a kernel K1. The second processor executes three applications A4, A5, and A6, and a kernel K2. The kernel is a portion of the processor's operating system that provides low-level control/access to memory and other processor peripherals, for the benefit of applications and higher-level portions of the operating system. Typically, system calls are provided by which the operating system allows applications to access kernel functionality in a controlled manner.
In FIG. 1, the portion of the kernels K1 and K2 shown implements a Transmission Control Protocol (TCP) portion of a network stack. When a TCP connection is established between a port bound to application A1 and a port bound to application A4, for example, both kernels maintain a state (numbered 1 in FIG. 1) for the connection. The connection state comprises the condition of the local socket, negotiated variables, an acknowledgment sequence number state for sent octets, a resend buffer of packets that have been transmitted but not yet acknowledged by the receiving end, and a receive buffer used to correctly order received packet data. In FIG. 1, each of applications A1-A3 has an established connection with each of applications A4-A6, for a total of nine numbered TCP/IP connections.
A set of transmit and receive port buffers provides an interface between each application and its bound port. Application A1 communicates with a set of port buffers PB1, application A2 communicates with a set of port buffers PB2, etc. When A1 writes packet data to PB1 for delivery to A4, for example, TCP will handle guaranteed delivery of the packet data to PB4. All packet data that was written to PB1 in a certain order will be delivered to PB4 in the same order, albeit possibly intermingled with other packet data from connections 4 and 7. Application A4 merely retrieves the packet data from PB4 and interprets the data in whatever manner A4 expects.
Another method of setting up IPC between two applications is with the User Datagram Protocol (UDP). UDP is described in Postel, J., “User Datagram Protocol”, STD 6, RFC 768, August 1980, which is incorporated herein by reference. Like TCP, UDP is a transport layer protocol that runs on top of IP, and provides some error detection. Also like TCP, UDP uses the concept of a socket as a combination of an IP address and a port number. Unlike TCP, however, UDP is connectionless, providing only best-effort delivery of a packet with no acknowledgement of successful delivery or guarantees as to in-sequence delivery, duplicate-free delivery, or delivery at all should a first attempt at delivery of a packet fail. Because of these attributes, IPC over UDP relies on the applications themselves to provide a handshaking mechanism suitable to the situation.
To use UDP, an application binds to a port on its local processor. Any UDP packets received by the processor with that destination port number are buffered for consumption by the bound application. The bound application can also send packets from its socket to a remote socket. Thus two applications can communicate with each other using UDP by merely writing packets to each other's sockets, with no connection establishment phase or UDP state to be consulted.
FIG. 2 illustrates an IPC network configuration 200 between two processors that use UDP/IP for delivery of IPC services. The first processor executes three applications A1, A2, and A3, and a kernel K1. The second processor executes three applications A4, A5, and A6, and a kernel K2. In FIG. 2, the portion of the kernels K1 and K2 shown implements a UDP portion of a network stack. When a UDP packet is received by the processor, the UDP packet is checked for bit errors, and assuming that none exist, the packet is written to the appropriate buffer for the destination socket indicated in the UDP packet. If the packet is received with errors, specifies a port that is not bound to an application, or cannot be forwarded to the appropriate port because the buffer is full, the packet is simply dropped.
In FIG. 2, each of applications A1-A6 implements an acknowledgement (ACK) function. Applications using UDP with an ACK function actually create two UDP sockets for themselves—a request socket, or queue, on which messages (requests) arrive from other processes, and an acknowledgment socket, or queue, on which acknowledgments arrive. Accordingly, when for example application A1 sends a message to application A4, it creates a UDP packet addressed to A4's request socket. When A4 retrieves the application A1 message successfully from its request socket, its ACK function creates an acknowledgment packet addressed to A1's acknowledgment socket. When A1 retrieves and processes the acknowledgment from its acknowledgment socket, it knows that A4 successfully received the message. The applications saves state necessary for these functions, and may also optionally perform reordering and/or retransmission such as those described above for TCP.